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Energy-Efficient Features of Internet of Things Protocols 
Abstract 


This document describes the challenges for energy-efficient protocol 
operation on constrained devices and the current practices used to 
overcome those challenges. It summarizes the main link-layer 
techniques used for energy-efficient networking, and it highlights 
the impact of such techniques on the upper-layer protocols so that 
they can together achieve an energy-efficient behavior. The document 
also provides an overview of energy-efficient mechanisms available at 
each layer of the IETF protocol suite specified for constrained-node 
networks. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are candidates for any level of Internet 
Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8352. 
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1. Introduction 


Network systems for monitoring the physical world contain many 
battery-powered or energy-harvesting devices. For example, in an 
environmental monitoring system or a temperature and humidity 
monitoring system, there may not be always on and sustained power 
supplies for the potentially large number of constrained devices. In 
such deployment scenarios, it is necessary to optimize the energy 
consumption of the constrained devices. In this document, we 
describe techniques that are in common use at Layer 2 and at Layer 3, 
and we indicate the need for higher-layer awareness of lower-layer 
features. 


Many research efforts have studied this "energy efficiency" problem. 
Most of this research has focused on how to optimize the system’s 
power consumption in certain deployment scenarios or how an existing 
network function such as routing or security could be more energy 
efficient. Only few efforts have focused on energy-efficient designs 
for IETF protocols and standardized network stacks for such 
constrained devices [CLASS1-CoAP]. 


The IETF has developed a suite of Internet protocols suitable for 
such constrained devices, including IPv6 over Low-Power Wireless 
Personal Area Networks (6LOWPAN) [RFC6282] [RFC6775] [RFC4944], the 
IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) 
[RFC6550], and the Constrained Application Protocol (CoAP) [RFC7252]. 
This document tries to summarize the design considerations for making 
the IETF constrained protocol suite as energy efficient as possible. 
While this document does not provide detailed and systematic 
solutions to the energy-efficiency problem, it summarizes the design 
efforts and analyzes the design space of this problem. In 
particular, it provides an overview of the techniques used by the 
lower layers to save energy and how these may impact on the upper 
layers. Cross-layer interaction is therefore considered in this 
document from this specific point of view. Providing further design 
recommendations that go beyond the layered protocol architecture is 
out of the scope of this document. 


After reviewing the energy-efficient designs of each layer, we 
summarize the document by presenting some overall conclusions. 
Though the lower-layer communication optimization is the key part of 
energy-efficient design, the protocol design at the upper layers is 
also important to make the device energy efficient. 


1.1. Terminology 


Terms used in this document are defined in [RFC7228] [CNN-TERMS]. 
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2. Overview 


The IETF has developed protocols to enable end-to-end IP 
communication between constrained nodes and fully capable nodes. 
This work has expedited the evolution of the traditional Internet 
protocol stack to a lightweight Internet protocol stack. As shown in 
Figure 1 below, the IETF has developed CoAP as the application layer 
and 6LOWPAN as the adaption layer to run IPv6 over IEEE 802.15.4 
[IEEE802.15.4] and Bluetooth Low Energy (also referred to as 
Bluetooth LE and BILE), with the support of routing by RPL and 
efficient neighbor discovery by 6LOWPAN Neighbor Discovery (6LOWPAN- 
ND). 6LOWPAN is currently being adapted by the 6lo Working Group to 
support IPv6 over various other technologies, such as ITU-T G.9959 
[G9959], Digital Enhanced Cordless Telecommunications Ultra Low 
Energy (DECT ULE) [TS102], Building Automation and Control Networks 
Master-Slave/Token-Passing (BACnet MS/TP) [MSTP], and Near Field 
Communication [NFC]. 


4+----- + 4+----- + +----- + +------ + 
HTTP | | FTP | |SNMP | | CoaP | 
4+----- + 4+----- + 4+----- + 4+------ + 
\ / / / \ 
4+----- + 4+----- + 4+----- + +----- + 
| TCP | | UDP | | TCP | | UDP | 
4+----- + 4+----- + ===> 4+----- + 4+----- + 
\ / \ / 
4+----- + +------ +  +------- + 4+------ + 4+----- + 
RTG |--| IPv6é |--|ICMP/ND| | IPv6 |---| RTG 
4+----- + +------ +  +------- + 4+------ + +----- + 
ae eer a 4+---------- + 
| MAC/PHY | | 6Lo  |--|6LoWPAN-ND 
4+------- + 4+------- +  +---------- + 
ee 
|MAC/PHY | 
+------- + 


Figure 1: Traditional and Lightweight Internet Protocol Stack 


There are numerous published studies reporting comprehensive 
measurements of wireless communication platforms [Powertrace]. As an 
example, below we list the energy-consumption profile of the most 
common operations involved in communication on a prevalent sensor 
node platform. The measurement was based on the Tmote Sky with 
ContikiMAC [ContikiMAC] as the Radio Duty Cycling algorithm. From 
this and many other measurement reports (e.g., [ANO79]), we can see 
that the energy consumption of optimized transmission and reception 
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are in the same order. For IEEE 802.15.4 [IEEE802.15.4] and Ultra 
WideBand (UWB) links, transmitting may actually be even cheaper than 
receiving. It also shows that broadcast and non-synchronized 
communication transmissions are energy costly because they need to 
acquire the medium for a long time. 


tan E E EE +--------------- + 
| Activity | Energy | 
| | (microjoules) | 
kaaas aa a a 4+--------------- + 
| Broadcast reception | 178 | 
Peas > SaaS aes Se Ss Sas Ses Ss=s5 +--------------- + 
| Unicast reception | 222 | 
tan O +--------------- + 
| Broadcast transmission | 1790 | 
te eae oa ne eae esas Sane ee See oe ee t--------------- + 
| Non-synchronized unicast transmission | 1090 | 
i A ERS E E A a NNE ATT 4+--------------- + 
| Synchronized unicast transmission | 120 | 
tan O A E S 4+--------------- + 
| Unicast TX to awake receiver | 96 | 
A A E R AA AE NE A E S A + 
| Listening (for 1000 ms) | 63000 | 
A E a T T +--------------- + 


Figure 2: Power Consumption of Common Operations Involved in 
Communication on the Tmote Sky with ContikiMAC 


At the Physical layer, one approach that may reduce the energy 
consumption of a device that uses a wireless interface is based on 
reducing the device transmit power level, as long as the intended 
next hop(s) is still within range of the device. In some cases, if 
node A has to transmit a message to node B, a solution to reduce node 
A transmit power is to leverage an intermediate device, e.g., node C 
as a message forwarder. Let d be the distance between node A and 
node B. Assuming free-space propagation, where path loss is 
proportional to d*2, if node C is placed right in the middle of the 
path between A and B (that is, at a distance d/2 from both node A and 
node B), the minimum transmit power to be used by node A (and by node 
C) is reduced by a factor of 4. However, this solution requires 
additional devices, it requires a routing solution, and it also 
increases transmission delay between A and B. 
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Medium Access Control and Radio Duty Cycling 


In networks, communication and power consumption are interdependent. 
The communication device is typically the most power-consuming 
component, but merely refraining from transmissions is not enough to 
achieve a low power consumption: the radio may consume as much power 
in listen mode as when actively transmitting. This illustrates the 
key problem known as idle listening, whereby the radio of a device 
may be in receive mode (ready to receive any message), even if no 
message is being transmitted to that device. Idle listening can 
consume a huge amount of energy unnecessarily. To reduce power 
consumption, the radio must be switched completely off -- duty-cycled 
—- as much as possible. By applying duty cycling, the lifetime of a 
device operating on a common button battery may be on the order of 
years, whereas otherwise the battery may be exhausted in a few days 
or even hours. Duty cycling is a technique generally employed by 
devices that use the Pl strategy [RFC7228], which need to be able to 
communicate on a relatively frequent basis. Note that a more 
aggressive approach to save energy relies on the PO (Normally-off) 
strategy, whereby devices sleep for very long periods and communicate 
infrequently, even though they spend energy in network reattachment 
procedures. 


From the perspective of Medium Access Control (MAC) and Radio Duty 

Cycling (RDC), all upper-layer protocols, such as routing, RESTful 

communication, adaptation, and management flows, are applications. 

Since the duty-cycling algorithm is the key to energy efficiency of 
the wireless medium, it synchronizes transmission and/or reception 

requests from the higher layers. 


MAC and RDC are not in the scope of the IETF, yet lower-layer 
designers and chipset manufacturers take great care to save energy. 
By knowing the behaviors of these lower layers, engineers can design 
protocols that work well with them. The IETF protocols to be 
discussed in the following sections are the customers of the lower 
layers. 


1. Techniques for Radio Duty Cycling 


This subsection describes three main RDC techniques. Note that more 
than one of these techniques may be available or can even be combined 
in a specific radio technology: 


a) Channel sampling: In this solution, the radio interface of a 
device periodically monitors the channel for very short time 
intervals (i.e., with a low duty cycle) with the aim of detecting 
incoming transmissions. In order to make sure that a receiver 
can correctly receive a transmitted data unit, the sender may 
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prepend a preamble of a duration at least the sampling period to 
the data unit to be sent. Another option for the sender is to 
repeatedly transmit the data unit instead of sending a preamble 


before the data unit. Once a transmission is detected by a 
receiver, the receiver may stay awake until the complete 
reception of the data unit. Examples of radio technologies that 


use preamble sampling include ContikiMAC, the Coordinated Sampled 
Listening (CSL) mode of IEEE 802.15.4e [IEEE802.15.4], and the 
Frequently Listening (FL) mode of ITU-T G.9959 [G9959]. 


b) Scheduled transmissions: This approach allows a device to know 
the particular time at which it should be awake (during some time 
interval) in order to receive data. Otherwise, the device may 
remain in sleep mode. The decision on the times at which 
communication is attempted relies on some form of negotiation 
between the involved devices. Such negotiation may be performed 
per transmission or per session/connection. Bluetooth Low Energy 
(Bluetooth LE) is an example of a radio technology based on this 
mechanism. 


c) Listen after send: This technique allows a node to remain in 
sleep mode by default, then wake up and poll a sender (which must 
be ready to receive a poll message) for pending transmissions. 
After sending the poll message, the node remains in receive mode 
and is ready for a potential incoming transmission. After a 
certain time interval, the node may go back to sleep. For 
example, this technique is used in the Receiver Initiated 
Transmission (RIT) mode of IEEE 802.15.4e [IEEE802.15.4] and in 
the transmission of data between a coordinator and a device in 
the 2003 version of IEEE 802.15.4 [IEEE802.15.4]. 


3.2. Latency and Buffering 


The latency of a data unit transmission to a duty-cycled device is 
equal to or greater than the latency of transmitting to an always-on 
device. Therefore, duty cycling leads to a trade-off between energy 
consumption and latency. Note that in addition to a latency 
increase, RDC may introduce latency variance since the latency 
increase is a random variable (which is uniformly distributed if duty 
cycling follows a periodic behavior). 


On the other hand, due to the latency increase introduced by duty 
cycling, a sender waiting for a transmission opportunity may need to 
store subsequent outgoing packets in a buffer. This buffering would 
increase memory requirements and potentially incur queuing wait 
times. Such wait times would in turn contribute to packet 
transmission delay and increase the probability of buffer overflow, 
leading to losses. 
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3.3. Throughput 


Although throughput is not typically a key concern in constrained- 
node network applications, it is indeed important in some services in 
such networks, such as over-the-air software updates or when off-line 
sensors accumulate measurements that have to be quickly transferred 
when there is an opportunity for connectivity. 


Since RDC introduces inactive intervals in energy-constrained 
devices, it reduces the throughput that can be achieved when 
communicating with such devices. There exists a trade-off between 
the achievable throughput and energy consumption. 


3.4. Radio Interface Tuning 


The parameters controlling the radio duty cycle have to be carefully 
tuned to achieve the intended application and/or network 
requirements. On the other hand, upper layers should take into 
account the expected latency and/or throughput behavior due to RDC. 
The next subsection provides details on key parameters controlling 
RDC mechanisms, and thus fundamental trade-offs, for various examples 
of relevant low-power radio technologies. 


3.5. Packet Bundling 


Another technique that may be useful to increase communication energy 
efficiency is packet bundling. This technique, which is available in 
several radio interfaces (e.g., LTE and some 802.11 variants), allows 
for aggregation of several small packets into a single large packet. 
Header and communication overhead is therefore reduced. 


3.6. Power Save Services Available in Example Low-Power Radios 


This subsection presents power save services and techniques used in a 
few relevant examples of wireless low-power radios: IEEE 802.11 
[IEEE802.11], Bluetooth LE, and IEEE 802.15.4 [IEEE802.15.4]. Fora 
more detailed overview of each technology, the reader may refer to 
the literature or to the corresponding specifications. 


3.6.1. Power Save Services Provided by IEEE 802.11 


IEEE 802.11 [IEEE802.11] defines the Power Save Mode (PSM) whereby a 
station may indicate to an Access Point (AP) that it will enter a 
sleep mode state. While the station is sleeping, the AP buffers any 
frames that should be sent to the sleeping station. The station 
wakes up every listen interval (which can be a multiple of the beacon 
interval) in order to receive beacons. The AP signals, by means of a 
beacon field, whether there is data pending for the station or not. 
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If there are not frames to be sent to the station, the latter may get 
back to sleep mode. Otherwise, the station may send a message 
requesting the transmission of the buffered data and stay awake in 
receive mode. 


IEEE 802.11lv [IEEE802.11] further defines mechanisms and services for 
power save of stations/nodes that include Flexible Multicast Service 
(FMS), Proxy ARP advertisement, extended sleep modes, and traffic 
filtering. Upper-layer protocol’s knowledge of such capabilities, 
provided by the lower layer, enables better interworking. 


These services include: 


Proxy ARP: The Proxy ARP capability enables an Access Point (AP) to 
indicate that the non-AP station (STA) will not receive ARP 
frames. The Proxy ARP capability enables the non-AP STA to remain 
in power save mode for longer periods of time. 


Basic Service Set (BSS) Max Idle Period Management: Enables an AP to 
indicate a time period during which the AP does not disassociate a 
STA due to non-receipt of frames from the STA. This supports 
improved STA power saving and AP resource management. 


FMS: A service in which a non-AP STA can request a multicast 
delivery interval longer than the Delivery Traffic Indication 
Message (DTIM) interval for the purposes of lengthening the period 
of time a STA may be in a power save state. 


Traffic Filtering Service (TFS): A service provided by an AP toa 
non-AP STA that can reduce the number of frames sent to the STA by 
dropping individually addressed frames that do not match traffic 
filters specified by the STA. 


Using the above services provided by the lower layer, the constrained 
nodes can achieve either client-initiated power save (via TFS) or 
network-assisted power save (Proxy ARP, BSS Max Idle Period, and 
FMS). 


Upper-layer protocols should synchronize with the parameters such as 
FMS interval and BSS MAX Idle Period so that the wireless 
transmissions are not triggered periodically. 
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3.6.2. Power Save Services Provided by Bluetooth LE 


Bluetooth LE is a wireless low-power communications technology that 
is the hallmark component of the Bluetooth 4.0, 4.1, and 4.2 
specifications [Bluetooth42]. BTLE has been designed for the goal of 
ultra-low power consumption. IPv6 can be run IPv6 over Bluetooth LE 
networks by using a 6LOWPAN variant adapted to BTLE [RFC7668]. 


Bluetooth LE networks comprise a master and one or more slaves, which 
are connected to the master. The Bluetooth LE master is assumed to 
be a relatively powerful device, whereas a slave is typically a 
constrained device (e.g., a Class 1 device). 


Medium access in Bluetooth LE is based on a Time-Division Multiple 
Access (TDMA) scheme that is coordinated by the master. This device 
determines the start of connection events in which communication 
between the master and a slave takes place. At the beginning of a 
connection event, the master sends a poll message, which may 


encapsulate data, to the slave. The latter must send a response, 
which may also contain data. The master and the slave may continue 
exchanging data until the end of the connection event. The next 


opportunity for communication between the master and the slave will 
be in the next connection event scheduled for the slave. 


The time between consecutive connection events is defined by the 


connInterval parameter, which may range between 7.5 ms and 4 s. The 
slave may remain in sleep mode from the end of its last connection 
event until the beginning of its next connection event. Therefore, 


Bluetooth LE is duty-cycled by design. Furthermore, after having 
replied to the master, a slave is not required to listen to the 
master (and thus may keep the radio in sleep mode) for 
connSlaveLatency consecutive connection events. connSlaveLatency is 
an integer parameter between 0 and 499 that should not cause link 
inactivity for more than connSupervisionTimeout time. The 
connSupervisionTimeout parameter is in the range between 100 ms and 
328°, 


Upper-layer protocols should take into account the medium access and 
duty-cycling behavior of Bluetooth LE. In particular, connInterval, 
connSlaveLatency, and connSupervisionTimeout determine the time 
between two consecutive connection events for a given slave. The 
upper-layer packet generation pattern and rate should be consistent 
with the settings of the aforementioned parameters (and vice versa). 
For example, assume connInterval = 4 seconds, connSlaveLatency = 

7 seconds, and connSupervisionTimeout = 32 seconds. With these 
settings, communication opportunities between a master and a slave 
will occur during a given interval every 32 seconds. Duration of the 
interval will depend on several factors, including number of 
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connected slaves, amount of data to be transmitted, etc. In the 
worst case, only one data unit can be sent from master to slave (and 
vice versa) every 32 seconds. 


3.6.3. Power Save Services in IEEE 802.15.4 


IEEE 802.15.4 [IEEE802.15.4] is a family of standard radio interfaces 
for low-rate, low-power wireless networking. Since the publication 
of its first version in 2003, IEEE 802.15.4 [IEEE802.15.4] has become 
the de facto choice for a wide range of constrained-node network 
application domains and has been a primary target technology of 
various IETF working groups such as 6LOWPAN [RFC6282] [RFC6775] 


[RFC4944] and 6TiSCH [ARCH-6TiSCH]. IEEE 802.15.4 [IEEBE802.15.4] 
specifies a variety of related Physical layer (PHY) and MAC layer 
functionalities. 


IEEE 802.15.4 [IEEE802.15.4] defines three roles called device, 
coordinator, and Personal Area Network (PAN) coordinator. The device 
role is adequate for nodes that do not implement the complete IEEE 
802.15.4 [IEEE802.15.4] functionality and is mainly targeted for 
constrained nodes with a limited energy source. The coordinator role 
includes synchronization capabilities and is suitable for nodes that 
do not suffer severe constraints (e.g., a mains-—powered node). The 
PAN coordinator is a special type of coordinator that acts as a 
principal controller in an IEEE 802.15.4 [IEEE802.15.4] network. 


IEEE 802.15.4 [IEEE802.15.4] defines two main types of networks 
depending on their configuration: beacon-enabled and non-beacon- 
enabled networks. In the first network type, coordinators 
periodically transmit beacons. The time between beacons is divided 
in three main parts: the Contention Access Period (CAP), the 
Contention Free Period (CFP), and an inactive period. In the first 
period, nodes use slotted Carrier Sense Multiple Access with 
Collision Avoidance (CSMA/CA) for data communication. In the second 
one, a TDMA scheme controls medium access. During the idle period, 
communication does not take place, and thus the inactive period is a 
good opportunity for nodes to turn the radio off and save energy. 

The coordinator announces in each beacon the list of nodes for which 
data will be sent in the subsequent period. Therefore, devices may 
remain in sleep mode by default and wake up periodically to listen to 
the beacons sent by their coordinator. If a device wants to transmit 
data, or learns from a beacon that it is an intended destination, 
then it will exchange messages with the coordinator (and thus consume 
energy). An underlying assumption is that when a message is sent to 
a coordinator, the radio of the coordinator will be ready to receive 
the message. 
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The beacon interval and the duration of the active portion of the 
beacon interval (i.e., the CAP and the CFP), and thus the duty cycle, 
can be configured. The parameters that control these times are 
called macBeaconOrder and macSuperframeOrder, respectively. As an 
example, when IEEE 802.15.4 [IEEE802.15.4] operates in the 2.4 GHz 
PHY, both times can be (independently) set to values in the range 
between 15.36 ms and 251.6 s. 


In the beaconless mode, nodes use unslotted CSMA/CA for data 
transmission. The device may be in sleep mode by default and may 
activate its radio to either i) request to the coordinator whether 
there is pending data for the device, or to ii) transmit data to the 
coordinator. The wake-up pattern of the device, if any, is out of 
the scope of IEEE 802.15.4 [IEEE802.15.4]. 


Communication between the two ends of an IEEE 802.15.4 [IEEE802.15.4] 
link may also take place in a peer-to-peer configuration, whereby 
both link ends assume the same role. In this case, data transmission 
can happen at any moment. Nodes must have their radio in receive 
mode and be ready to listen to the medium by default (which for 
battery-enabled nodes may lead to a quick battery depletion) or apply 
synchronization techniques. The latter are out of the scope of IEEE 
802.15.4 [IEEE802.15.4]. 


The main MAC layer IEEE 802.15.4 [IEEE802.15.4] amendment to date is 
TEEE 802.15.4e. This amendment includes various new MAC layer modes, 
some of which include mechanisms for low energy consumption. Among 
these, the Time-Slotted Channel Hopping (TSCH) is an outstanding mode 
that offers robust features for industrial environments, among 
others. In order to provide the functionality needed to enable IPv6 
over TSCH, the 6TiSCH Working Group was created. TSCH is based on a 
TDMA schedule whereby a set of timeslots are used for frame 
transmission and reception, and other timeslots are unscheduled. The 
latter timeslots may be used by a dynamic scheduling mechanism, 
otherwise, nodes may keep the radio off during the unscheduled 
timeslots, thus saving energy. The minimal schedule configuration 
specified in [RFC8180] comprises 101 timeslots; 95 of these timeslots 
are unscheduled and the timeslot duration is 15 ms. 


The previously mentioned CSL and RIT are also 802.15.4e modes 
designed for low energy. 


3.6.4. Power Save Services in DECT ULE 
DECT Ultra Low Energy (DECT ULE) is a wireless technology building on 
the key fundamentals of traditional DECT / Cordless Advanced 


Technology - internet and quality (CAT-iq) [EN300] but with specific 
changes to significantly reduce the power consumption at the expense 
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of data throughput [TS102]. DECT ULE devices typically operate on 
special power-optimized silicon but can connect to a DECT Gateway 
supporting traditional DECT/CAT-iq for cordless telephony and data as 
well as the DECT ULE extensions. IPv6 can be run over DECT ULE by 
using a 6LOWPAN variant [RFC8105]. 


DECT defines two major roles: the Portable Part (PP) is the power 
constrained device while the Fixed Part (FP) is the Gateway or base 
station in a star topology. Because TDMA/FDMA and Time-Division 
Duplex (TDD) using dynamic channel allocation for interference, DECT 
operates in license-free and reserved frequency bands. It provides 
good indoor (~50 m) and outdoor (~300 m) coverage. It uses a frame 
length of 10 ms divided into 24 timeslots, and it supports 
connection-oriented packet data and connection-less services. 


The FP usually transmits a so-called dummy bearer (beacon) that is 
used to broadcast synchronization, system, and paging information. 
The slot/carrier position of this dummy bearer can automatically be 
reallocated in order to avoid mutual interference with other DECT 
signals. 


At the MAC level, DECT ULE communications between FP and PP are 
initiated by the PP. An FP can initiate communication indirectly by 
sending a paging signal to a PP. The PP determines the timeslot and 
frequency in which the communication between FP and PP takes place. 
The PP verifies the radio timeslot/frequency position is unoccupied 
before it initiates its transmitter. An access-request message, 
which usually carries data, is sent to the FP. The FP sends a 
confirm message, which also may carry data. More data can be sent in 
subsequent frames. A MAC-level automatic retransmission scheme 
significantly improves the reliability of data transfer. A 
segmentation and reassembly scheme supports transfer of larger, 
higher-layer Service Data Units (SDUs) and provides data integrity 
checks. The DECT ULE packet data service ensures data integrity, 
proper sequencing, and duplicate protection but not guaranteed 
delivery. Higher-layer protocols have to take this into 
consideration. 


The FP may send paging information to PPs to trigger connection setup 
and indicate the required service type. The interval between paging 
information to a specific PP can be defined in the range of 10 ms to 
327 s. The PP may enter sleep mode to save power. The listening 
interval is defined by the PP application. For short sleep intervals 
(below ~10 seconds), the PP may be able to retain synchronization to 
the FP dummy bearer and only turn on the receiver during the expected 
timeslot. For longer sleep intervals, the PP can’t keep 
synchronization and has to search for, and resynchronize to, the FP 
dummy bearer. Hence, longer sleep intervals reduce the average 
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energy consumption but add an energy consumption penalty for 
acquiring synchronization to the FP dummy bearer. The PP can obtain 
all information to determine paging and acquire synchronization 
information in a single reception of one full timeslot. 


Packet data latency is normally 30 ms for short packets (below or 
equal to 32 octets), however, if retry and back-off scenarios occur, 
the latency is increased. The latency can actually be reduced to 
about 10 ms by doing energy consuming Received Signal Strength 
Indication (RSSI) scanning in advance. In the direction from FP to 
PP, the latency is usually increased by the used paging interval and 
the sleep interval. The MAC layer can piggyback commands to improve 
efficiency (reduce latency) of higher-layer protocols. Such commands 
can instruct the PP to initiate a new packet transfer in N frames 
without the need for resynchronization and can listen to paging or 
instruct the PP to stay in a higher duty-cycle paging detection mode. 


The DECT ULE technology allows a per-PP configuration of paging 
interval, MTU size, reassembly window size, and higher-layer service 
negotiation and protocol. 


4. IP Adaptation and Transport Layer 


6LOWPAN provides an adaptation layer designed to support IPv6 over 
IEEE 802.15.4 [IEEE802.15.4]. 6LOWPAN affects the energy-efficiency 
problem in three aspects, as follows. 


First, 6LOWPAN provides one fragmentation and reassembly mechanism, 
which is aimed at solving the packet size issue in IPv6 and could 
also affect energy efficiency. IPv6 requires that every link in the 
Internet have an MTU of 1280 octets or greater. On any link that 
cannot convey a 1280-octet packet in one piece, link-specific 
fragmentation and reassembly must be provided at a layer below IPv6 
[RFC8200]. 6LOWPAN provides fragmentation and reassembly below the 
IP layer to solve the problem. One of the benefits from placing 
fragmentation at a lower layer such as the 6LOWPAN layer is that it 
can avoid the presence of more IP headers because fragmentation at 
the IP layer will produce more IP packets, each one carrying its own 
IP header. However, performance can be severely affected if, after 
IP layer fragmentation, then 6LOWPAN fragmentation happens as well 
(e.g., when the upper layer is not aware of the existence of the 


fragmentation at the 6LOWPAN layer). One solution is to require that 
the higher layers have an awareness of the lower-layer features and 
generate small enough packets to avoid fragmentation. In this 


regard, the Block option in CoAP can be useful when CoAP is used at 
the application layer [RFC7959]. 
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Secondly, 6LOWPAN swaps computing with communication. 6LOWPAN applies 
compression of the IPv6 header. Subject to the packet size limit of 
IEEE 802.15.4 [IEEE802.15.4], a 40-octet-long IPv6é header and an 8 or 
20-octet-long UDP and TCP header will consume even more packet space 
than the data itself. 6LOWPAN provides IPv6 and UDP header 
compression at the adaptation layer. Therefore, a lower amount of 
data will be handled by the lower layers, whereas both the sender and 
receiver will spend more computing power on the compression and 
decompression of the packets over the air. Compression can also be 
performed at higher layers (see Section 6.4). 


Finally, the 6LOWPAN Working Group developed the energy-efficient 
Neighbor Discovery called 6LOWPAN-ND, which is an energy-efficient 
replacement of the IPv6 ND in constrained environments. IPv6 
Neighbor Discovery was not designed for non-transitive wireless 
links, as its heavy use of multicast makes it inefficient and 
sometimes impractical in a low-power and lossy network. 6LOWPAN-ND 
describes simple optimizations to IPv6 Neighbor Discovery, its 
addressing mechanisms, and duplicate address detection for Low-Power 
Wireless Personal Area Networks and similar networks. However, 
6LOWPAN-ND does not modify Neighbor Unreachability Detection (NUD) 
timeouts, which are very short (by default three transmissions spaced 
1 second apart). NUD timeout settings should be tuned to take into 
account the latency that may be introduced by duty-cycled mechanisms 
at the link layer or the alternative, less impatient NUD algorithms 
should be considered [RFC7048]. 


IPv6 underlies the higher-layer protocols, including both TCP/UDP 
transport and applications. By design, the higher-layer protocols do 
not typically have specific information about the lower layers and 
thus cannot solve the energy-efficiency problem. 


The network stack can be designed to save computing power. For 
example, the Contiki implementation has multiple cross-layer 
optimizations for buffers and energy management, e.g., the computing 
and validation of UDP/TCP checksums without the need of reading IP 
headers from a different layer. These optimizations are software 
implementation techniques and are out of the scope of the IETF and 
the LWIG Working Group. 


5. Routing Protocols 


RPL [RFC6550] is a routing protocol designed by the IETF for 
constrained environments. RPL exchanges messages periodically and 
keeps routing states for each destination. RPL is optimized for the 
many-to-one communication pattern (where network nodes primarily send 
data towards the border router) but has provisions for any-to-any 
routing as well. 
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6. 


6. 


The authors of the Powertrace tool [Powertrace] studied the power 
profile of RPL. Their analysis divides the routing protocol into 
control and data traffic. The control plane carries ICMP messages to 
establish and maintain the routing states. The data plane carries 
any application that uses RPL for routing packets. The study has 
shown that the power consumption of the control traffic goes down 
over time in a relatively stable network. The study also reflects 
that the routing protocol should keep the control traffic as low as 
possible to make it energy friendly. The amount of RPL control 
traffic can be tuned by setting the Trickle [RFC6206] algorithm 
parameters (i.e., Imin, Imax, and k) to appropriate values. However, 
there exists a trade-off between energy consumption and other 
performance parameters such as network convergence time and 
robustness. 


RFC 6551 [RFC6551] defines routing metrics and constraints to be used 
by RPL in route computation. Among others, RFC 6551 specifies a Node 
Energy object that allows to provide information related to node 
energy, such as the energy source type or the estimated percentage of 
remaining energy. Appropriate use of energy-based routing metrics 
may help to balance energy consumption of network nodes, minimize 
network partitioning, and increase network lifetime. 


Application Layer 
1. Energy-Efficient Features in CoAP 


CoAP [RFC7252] is designed as a RESTful application protocol that 
connects the services of smart devices to the World Wide Web. CoAP 
is not a chatty protocol. It provides basic communication services 
such as service discovery and GET/POST/PUT/DELETE methods with a 
binary header. 


Energy efficiency is part of the CoAP protocol design. CoAP uses a 
fixed-length binary header of only four bytes that may be followed by 
binary options. To reduce regular and frequent queries of the 
resources, CoAP provides an observe mode in which the requester 
registers its interest of a certain resource and the responder will 
report the value whenever it was updated. This reduces the request/ 
response round trips while keeping information exchange an ubiquitous 
service; an energy-constrained server can remain in sleep mode during 
the period between observe notification transmissions. 


Furthermore, [RFC7252] defines CoAP proxies that can cache resource 
representations previously provided by sleepy CoAP servers. The 
proxies themselves may respond to client requests if the 
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corresponding server is sleeping and the resource representation is 
recent enough. Otherwise, a proxy may attempt to obtain the resource 
from the sleepy server. 


CoAP proxy and cache functionality may also be used to perform data 
aggregation. This technique allows a node to receive data messages 
(e.g., carrying sensor readings) from other nodes in the network, 
perform an operation based on the content in those messages, and 
transmit the result of the operation. Such operation may simply be 
intended to use one packet to carry the readings transported in 
several packets (which reduces header and transmission overhead), or 
it may be a more sophisticated operation, possibly based on 
mathematical, logical, or filtering principles (which reduces the 
payload size to be transmitted). 


6.2. Sleepy Node Support 


Beyond these features of CoAP, there have been a number of proposals 
to further support sleepy nodes at the application layer by 
leveraging CoAP mechanisms. A good summary of such proposals can be 
found in [SLEEPY-DEVICES], while an example application (in the 
context of illustrating several security mechanisms) in a scenario 
with sleepy devices has been described [CRYPTO-SENSORS]. Approaches 
to support sleepy nodes include exploiting the use of proxies, 
leveraging the resource directory [CORE-RD], or signaling when a node 
is awake to the interested nodes. Recent work defines publish- 
subscribe and message queuing extensions to CoAP and the resource 
directory in order to support devices that spend most of their time 
asleep [CoAP-BROKER]. Notably, this work has been adopted by the 
CoRE Working Group. 


In addition to the work within the scope of CoAP to support sleepy 
nodes, other specifications define application-layer functionality 
for the same purpose. The Lightweight Machine-to-Machine (LwM2M) 
specification from the Open Mobile Alliance (OMA) defines a queue 
mode whereby an LwM2M Server queues requests to an LwM2M Client until 
the latter (which may often stay in sleep mode) is online. LwM2M 
functionality operates on top of CoAP. 


oneM2M defines a CoAP binding with an application-layer mechanism for 
sleepy nodes [oneM2M]. 


6.3. CoAP Timers 
CoAP offers mechanisms for reliable communication between two CoAP 
endpoints. A CoAP message may be signaled as a confirmable (CON) 


message, and an acknowledgment (ACK) is issued by the receiver if the 
CON message is correctly received. The sender starts a 
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Retransmission Timeout (RTO) for every CON message sent. The initial 
RTO value is chosen randomly between 2 and 3 s. If an RTO expires, 
the new RTO value is doubled (unless a limit on the number of 
retransmissions has been reached). Since duty cycling at the link 
layer may lead to long latency (i.e., even greater than the initial 
RTO value), CoAP RTO parameters should be tuned accordingly in order 
to avoid spurious RTOs that would unnecessarily waste node energy and 
other resources. On the other hand, note that CoAP can also run on 
top of TCP [RFC8323]. In that case, similar guidance applies to TCP 
timers, albeit with greater motivation to carefully configure TCP RTO 
parameters since [RFC6298] reduced the default initial TCP RTO to 1 
second, which may interact more negatively with duty-cycled links 
than default CoAP RTO values. 


6.4. Data Compression 


Another method intended to reduce the size of the data units to be 
communicated in constrained-node networks is data compression, which 
allows to encode data using fewer bits than the original data 
representation. Data compression is more efficient at higher layers, 
particularly before encryption is used. In fact, encryption 
mechanisms may generate an output that does not contain redundancy, 
making it almost impossible to reduce the data representation size. 
In CoAP, messages may be encrypted by using Datagram Transport Layer 
Security (DTLS) or TLS when CoAP over TCP is used, which is the 
default mechanism for securing CoAP exchanges. 


7. Summary and Conclusions 
We summarize the key takeaways of this document: 


a. Internet protocols designed by the IETF can be considered the 
customer of the lower layers (PHY, MAC, and duty cycling). To 
reduce power consumption, it is recommended that Layer 3 designs 
should operate based on awareness of lower-level parameters 
rather than treating the lower layer as a black box (see Sections 
4, 5, and 6). 


b. It is always useful to compress the protocol headers in order to 
reduce the transmission/reception power. This design principle 
has been employed by many protocols in the 6lo and CoRE Working 
Groups (see Sections 4 and 6). 


c. Broadcast and non-synchronized transmissions consume more than 
other TX/RX operations. If protocols must use these ways to 
collect information, reduction of their usage by aggregating 
similar messages together will be helpful in saving power (see 
Sections 2 and 6.1). 
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d. Saving power by sleeping as much as possible is used widely 
(Section 3). 


8. IANA Considerations 
This document has no IANA actions. 
9. Security Considerations 


This document discusses energy-efficient protocol design and does not 
incur any changes or challenges on security issues besides what the 
protocol specifications have analyzed. 
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